ソフトウェア開発において、設計のレビューは、成果物であるソフトウェアの品質に多大な影響を与えることが知られている。そのため、どのベンダー企業でも、公式な工程として、設計後の設計レビューは、「実施しなければならない」必須の活動として定義されている。しかし、常に時間の圧力が強くかかっている開発現場では、その「レビュー」に多大な時間が必要なことも知られている。

このようなことから、開発現場では、常に、品質の維持のためのレビューに投入すべき労力と、成果物の産出のための設計に投入すべき労力が天秤にかけられている。実施すべきことを強制されている現場では、有能な技術者を成果物の生産に投入し、そうでない技術者をレビューに投入して、労力不足の問題を解決しようとする例が多い。このことが、レビューの形骸化を招く。

そのような形骸化したレビューが多くなると、結果として実現したシステムは、欠陥が残存するリスクが増大する。そのような残存欠陥が、システムの利用時に実際に表出し、システムを障害を発生させる確率は高くない。つまり、システムの実利用が開始されても、潜在している欠陥がシステム障害の原因になるかどうかは、確率の問題である。運が良ければ、システム障害の原因にならないのである。

しかし、そのようなシステムに潜在する欠陥は、その後のシステムの改修や拡張時にも潜在したままであり、そのことを知らずに、そのシステムを再利用すると、本来の期待する機能通りにシステムが動作しなくなるため、何が原因かの究明ができない、複雑な故障現象が発生することがある。設計が終わって、20年後、30年後にそのような問題が起きた場合、その設計者やプログラムを行った技術者は、現場からいなくなっているため、原因不明の問題が発生し、それを正しく直すことができないのである。